-
Notifications
You must be signed in to change notification settings - Fork 38
feat: Compatibility with specifier imports #211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: Compatibility with specifier imports #211
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable with linting fixed.
21de0c1
to
a153042
Compare
return null | ||
} | ||
} | ||
} catch (error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} catch (error) { | |
} catch { |
Alternatively, we could also just add the cause
895825e
to
d31e359
Compare
3a000d2
to
1f7a010
Compare
1f7a010
to
2022e5e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, while I think we should add the cause
to the error we create in the catch clause.
Completely missed this, should I go ahead and add it? |
This PR adds compatibility with specifiers, for example:
module.exports = require('#main-entry-point');
These specifiers are defined inside the package.json file and can reference either a local file or an external module.
The proposed solution works as follows: whenever a require call begins with # (all specifiers must start with #), locates the package.json, extracts the corresponding reference from the imports field, and sets the newUrl with the resolved path, maintains any original process after that.